Virtual private network having automatic reachability updating

ABSTRACT

A unified policy management system for an organization including a central policy server and remotely situated policy enforcers. A central database and policy enforcer databases storing policy settings are configured as LDAP databases adhering to a hierarchical object oriented structure. Such structure allows the policy settings to be defined in an intuitive and extensible fashion. Changes in the policy settings made at the central policy server are automatically transferred to the policy enforcers for updating their respective databases. Each policy enforcer collects and transmits health and status information in a predefined log format and transmits it to the policy server for efficient monitoring by the policy server. For further efficiencies, the policy enforcement functionalities of the policy enforcers are effectively partitioned so as to be readily implemented in hardware. The system also provides for dynamically routed VPNs where VPN membership lists are automatically created and shared with the member policy enforcers. Updates to such membership lists are also automatically transferred to remote VPN clients. The system further provides for fine grain access control of the traffic in the VPN by allowing definition of firewall rules within the VPN. In addition, policy server and policy enforcers may be configured for high availability by maintaining a backup unit in addition to a primary unit. The backup unit become active upon failure of the primary unit.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. provisional applications60/138,849, 60/138,850, 60/139,033, 60/139,034 60/139,035, 60/139,036,60/139,038, 60/139,042, 60/139,043, 60/139,044, 60/139,047, 60/139,048,60/139,049, 60/139,052, 60/139,053, all filed on Jun. 10, 1999, and U.S.provisional application 60/139,076, filed on Jun. 11, 1999, the contentsof all of which are incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to computer networks, and moreparticularly, to devices and methods for providing efficientconfiguration, management, and updating of virtual private networksextending over remote sites across the Internet.

BACKGROUND OF THE INVENTION

The growth and proliferation of computers and computer networks allowbusinesses to efficiently communicate with their own components as wellas with their business partners, customers, and suppliers. However, theflexibility and efficiencies provided by such computers and computernetworks come with increasing risks, including security breaches fromoutside the corporation, accidental release of vital information fromwithin it, and inappropriate use of the LAN, WAN, Internet, or extranet.

In managing the growth of computer networks as well as addressing thevarious security issues, network managers often turn to network policymanagement services such as firewall protection, Network AddressTranslation, spam email filtering, DNS caching, Web caching, virtualprivate network (VPN) organization and security, and URL blocking forkeeping network users from accessing certain Web sites through use ofthe organization's ISP. Each policy management service, however,generally requires a separate device that needs to be configured,managed, and monitored. Furthermore, as an organization grows andspreads across multiple locations, the devices maintained alsomultiplies, multiplying the associated expenditures and efforts toconfigure, manage, and monitor the devices.

The solution to this problem is not as simple as just integratingmultiple network policy management functions into a single device ateach location and allowing each location to share its policy informationwith other locations. In fact, there are many obstacles and challengesin adopting such an approach. One of these challenges is devising ascheme for efficient configuration, management, and updating of VPNsextending over remote sites separated by the Internet. Typical InternetProtocol Security (IPSec) VPN tunnels are point-to-point entities withstatic reachability information, that is, information about which fellowVPN members they can reach for the networks behind each VPN gateway.Encrypting or otherwise tunneling traffic between many sites that havepotentially different dynamic routing protocols over an IPSec tunnel cantherefore be problematic. It may also be problematic to set up a fullymeshed VPN where every site has full connectivity to every other site ifthere are a large number of sites. Furthermore, VPN definitions aretypically an association of source and destination network addressesthat allow unrestricted access between the networks in the VPN, andproviding fine grained access control to such traffic may be difficult.

Accordingly, there remains a need in the art for a network managementsolution that overcomes these and other obstacles of the prior art.

SUMMARY OF THE INVENTION

The present invention is directed to a unified policy management systemallowing the efficient configuration, management, and updating of VPNsextending over remote sites separated by the Internet. The system allowseach endpoint in a VPN tunnel to aggregate and abstract out thereachability information of the networks associated with each endpoint.This information is then shared with all the other tunnel endpoints inthe same VPN. Furthermore, the system provides a hierarchicalorganization of VPNs facilitating the creation of fully-meshed VPNs. Inaddition, access control rules may be defined for a VPN to allow usersto have fine grain control over the traffic flowing through the VPN.

According to one embodiment of the invention, a computer networkincludes a first edge device coupled to a first private network and asecond edge device coupled to a second private network. The first andsecond edge devices preferably act as VPN tunnel endpoints allowingsecure communication between the first and second private networks. Inaddition, the first edge device is configured to create a first tablewith information of member networks reachable through the first edgedevice, and the second edge device is configured to create a secondtable with information of member networks reachable through the secondedge device. The first and edge devices share their membershipinformation with each other, allowing the creation of VPNs whose memberlists are dynamically compiled.

In one particular aspect of the invention, the communication between thefirst and second private networks is managed according to a securitypolicy associated with the member networks. The security policy isdefined for a security policy group, referred to as a VPN cloud,providing hierarchical organization of the group. The VPN cloud includesmember networks (hosts), users allowed to access the member networks,and a rule controlling access to the member networks. The hierarchicalorganization provided by the VPN clouds thus allows the networkadministrator to create fully meshed VPNs. The network administratorneed no longer manually configure each possible connection in the VPN,but only need to create a VPN cloud and specify the sites, users, andrules to be associated with the VPN. Each connection is then configuredbased on the configuration specified for the VPN cloud. The hierarchicalorganization thus facilitates the setup of a VPN with a large number ofsites.

In another aspect of the invention, the rule in the VPN is a firewallrule providing access control of the traffic among the member networks.Such firewall rules allow the administrator to have fine grained accesscontrol over the traffic that flows through the VPN, all within therealm of the encrypted access provided by such VPN.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features, aspects and advantages of the presentinvention will be more fully understood when considered with respect tothe following detailed description, appended claims and accompanyingdrawings wherein:

FIG. 1 is a schematic block diagram of an exemplary unified policymanagement system;

FIG. 2 illustrates the hierarchical object-oriented structure ofpolicies stored for an organization in accordance with the principles ofthe invention;

FIG. 3 is a schematic block diagram of a policy server in the policymanagement system of FIG. 1;

FIG. 4 is a schematic diagram of a central management sub-module in thepolicy server of FIG. 3;

FIG. 5 is an exemplary flow diagram of a device registration processcarried out by the central management sub-module of FIG. 4;

FIG. 6 is a screen illustration of an exemplary graphical user interfacefor registering a device;

FIG. 7 is a screen illustration of an exemplary global monitor userinterface presenting device health and status information;

FIG. 8 is a screen illustration of an exemplary graphical user interfaceprovided by a policy management sub-module in the policy server of FIG.3;

FIG. 9 is a screen illustration of an exemplary graphical user interfacefor managing system devices;

FIG. 10 is a screen illustration of an exemplary graphical userinterface for managing system hosts;

FIG. 11 is a screen illustration of an exemplary graphical userinterface for managing system services;

FIG. 12 is a screen illustration of an exemplary graphical userinterface for managing time groups;

FIG. 13 is a screen illustration of an exemplary graphical userinterface displaying a plurality of VPN clouds;

FIG. 14 is a screen illustration of an exemplary graphical userinterface for adding a new firewall policy;

FIG. 15 is a schematic functional block diagram of policy enforcersupdating their respective VPN membership information;

FIG. 16 is a block diagram of components in a self-extracting executablefor downloading by a remote VPN client;

FIG. 17 is a functional block diagram for downloading theself-extracting executable of FIG. 16;

FIG. 18 is a schematic block diagram of a policy enforcer in the policymanagement system of FIG. 1;

FIG. 19 is a more detailed schematic block diagram of a policy engine inthe policy enforcer of FIG. 18;

FIG. 20 is a more detailed schematic block diagram of a protocolclassification engine of the policy enforcer of FIG. 18;

FIG. 21 is a more detailed schematic block diagram of an Internetprotocol security engine in the policy enforcer of FIG. 18;

FIG. 22 is a schematic layout diagram of a common log format accordingto one embodiment of the invention;

FIG. 23 is a block diagram of an LDAP tree structure according to oneembodiment of the invention;

FIG. 24 is a more detailed block diagram of a branch of the LDAP tree ofFIG. 23;

FIG. 25 is a flow diagram for logging and propagating LDAP changes topolicy enforcers;

FIG. 26 is a schematic block diagram of a high availability systemincluding a primary unit and a backup unit;

FIG. 27 is a flow diagram of an exemplary status discovery processconducted by a high availability unit;

FIG. 28 is a flow diagram of a process for maintaining configurationinformation synchronized in the primary and backup units of FIG. 26;

FIG. 29 is an exemplary flow diagram of updating the primary and backupunits of FIG. 26 when they are both functional; and

FIG. 30 is an exemplary flow diagram of updating the primary and backupunits FIG. 26 when the primary is not functional.

DETAILED DESCRIPTION OF THE INVENTION

I. Unified Policy Management System Architecture

FIG. 1 is a schematic block diagram of an exemplary unified policymanagement system according to one embodiment of the invention. Asillustrated in FIG. 1, private local networks 102, 104, and 106 are allcoupled to a public network such as the Internet 108 via respectiverouters (generally identified at 110) and Internet Service Providers(ISPs) (not shown). Also coupled to the public Internet 108 via the ISPsare web surfers 112, dial-up network users 114, servers providingunauthorized web sites 116, email, spammers 118 sending out unsolicitedjunk email, and remote VPN clients 140 seeking access to the privatelocal networks 102.

According to one example, local network 102 connects users andresources, such as workstations, servers, printers, and the like, at afirst location of the organization, such as the organization'sheadquarters, and local network 104 connects users and resources at asecond location of the organization, such as a branch office.Furthermore, local network 106 connects users and resources of acustomer of the organization requiring special access to theorganization's users and resources. Authorized dial-up network users 114of the organization are respectively situated at remote locations fromthe first and second local networks, and also require special access tothe organization's users and resources. Furthermore, web surfers 112communicate with the organization's web server 120 over the publicInternet 108 and access the organization's web site.

Local network 102 includes a policy server 122 for defining and managingnetwork services and policies for the organization. The network policiesare a set of rules and instructions that determine the network'soperation, Such as firewall, VPN, bandwidth, and administrationpolicies. The firewall policies decide the network traffic that is to beallowed to flow from the public Internet 108 into the local networks102, 104, and the traffic that is to be blocked. The bandwidth policiesdetermine the kind of bandwidth that is to be allocated to the trafficflowing through the local networks. The VPN policies determine the rulesfor implementing multiple site connectivity across the local networks.The administration policies decide the users that have access toadministrative functions, the type of administrative functions allocatedto these users, and the policy enforcers 124, 126 on which these usersmay exercise such administrative functions. The firewall, VPN,bandwidth, and administration policies for the entire organization arepreferably stored in a policy-server database 130 maintained by thepolicy server 122.

Each local network 102, 104 also includes an edge device, referred to asa policy enforcer 124, 126, for controlling access to the network. Eachpolicy enforcer 124, 126 manages the network policies and services forthe users and resources of their respective local networks 102, 104, aspermitted by the policy server 122. Respective portions of the policyserver database 130 are copied to the policy enforcer databases 132, 134for allowing the policy enforcers to manage the network policies andservices for the local networks 102, 104.

According to one embodiment of the invention, the policy server 122 andpolicy enforcers 124, 126 may be implemented in a similar fashion as theFORT KNOX series of policy routers made by Alcatel Internetworking,Inc., of Milpitas, Calif.

II. Object Model for Network Policy Management

According to one embodiment of the invention, the policy server database130 and policy enforcer databases 132, 134 are LDAP databases adheringto a unified hierarchical object oriented structure. The LDAP directoryservice model is based on entries where each entry is a collection ofattributes referenced by a distinguished name (DN). Each of theattributes includes a type and one or more values. The type is typicallya mnemonic string, such as “o” for organization, “c” for country, or“mail” for email address. The values depend on the type of attribute.For example, a “mail” attribute may contain the value “babs@umich.edu.”A “jpegPhoto” attribute may contain a photograph in binary JPEG/JFIFformat. Additional details of the LDAP directory service model aredefined in RFC 1777 “The Lightweight Directory Access Protocol” (W.Yeong, T. Howes, and Kille, Network Working Group, March 1995) and “LDAPProgramming: Directory-enabled Applications with Lightweight DirectoryAccess Protocol” (T. Howes, and M. Smith, Macmillan TechnicalPublishing, 1997), incorporated herein by reference.

The entries in the LDAP database are preferably arranged in ahierarchical tree-like structure reflecting political, geographic,and/or organizational boundaries. Entries representing countries appearat the top of the tree. Below them are entries representing states ornational organizations. Below the states or national organizations maybe entries representing people, organization units, printers, documents,and the like.

FIG. 2 is a schematic layout diagram of a unified hierarchical objectoriented structure adhered by the policy server database 130 accordingto one embodiment of the invention. The policy enforcer databases 132,134 adhere to a similar structure except for a few differences. Forexample, the policy enforcer databases preferably do not contain apolicy server domain object 201 and related policy server objects, nor apolicy domain object 240.

As illustrated in FIG. 2, each object in the structure is preferablystored as an LDAP entry. At the top of the hierarchy is the policyserver domain object 201 including various policy server resources and aplurality of policy domains objects (generally referenced at 204). Eachpolicy domain object 240 is a grouping of policy enforcers that sharecommon policies. Each policy domain object 240 includes a resource rootobject 200 and a group root object 202. All policy management functionsare preferably implemented in terms of the resource objects whichinclude devices 204, users 206, hosts 208, services 210, and time 220.Thus, a firewall policy may be defined by simply assigning theparticular devices, users, hosts, services, and time applicable to thepolicy. The devices, users, hosts, and services are preferably organizedin groups 212, 214, 216, and 218, respectively, having a group name,description, and member information for a more intuitive way ofaddressing and organizing the resources.

Users 206 are preferably associated with a user domain providing asecure and efficient means of authenticating the user. Each user domainhas a single policy enforcer who is authorized to authenticate the user.Thus, user domains ensure that the authenticating agent is generallylocated in the same local network as the user. This helps eliminate thecost of network dependency or network latency during the userauthentication process. It should be noted, however, that users may alsoconstitute authorized dial-up users 114 and users from the customernetwork 106. These users contact a remote authenticating agent whichproxies the authentication back to the appropriate policy enforcer.

Hosts 208 are the various networks present in an organization. Forinstance, a particular LAN subnet may be specified as a host in thesystem. Hosts 208 are preferably organized based on their physicallocations within the organization. A host's physical location isidentified by the device (policy enforcer) 204 associated with the host.

Services 210 reflect the various services provided by the policy server122. Such services include, for example, multimediastreaming/conferencing, information retrieval, security andauthentication, database applications, mail applications, routingapplications, standard communication protocols, and the like. Attributesassociated with each service preferably include a service name,description, type (e.g. HTTP, HTTPS, FTP, TELNET, SMTP, Real Networks,and the like), and group.

Devices 204 are the policy enforcers 124, 126 at the edge of aparticular local network. Each device/policy enforcer preferablyincludes users 206 and a host/network 208 that is managed by the policyenforcer.

Time 220 is another dimension in controlling access to the networkresources. Various time objects covering a range of times may be createdand used in creating the firewall policies.

Similar to resources, network policies are also preferably defined interms of objects for a more efficient and intuitive definition of thepolicies. Policies are defined by the administrators and implemented bythe policy enforcers 124, 126 on the network traffic flowing between thepublic Internet 108 and the local networks 102 and 104.

According to one embodiment of the invention, a policy object 222includes a bandwidth policy 224, firewall policy 226, administrationpolicy 228, and VPN policy 230. The VPN policy 230 defines a securitypolicy for the member networks and includes one or more VPN clouds 232.Each VPN cloud 232 is an individual VPN or a group of VPNs defining asecurity policy group which includes a list of sites 234 and users 236who can communicate with each other. A site is preferably a set ofhosts/networks physically located behind one of the policy enforcers124, 126. In other words, a site is a definition of a network whichincludes the policy enforcer that is associated with it. The policyenforcers for the sites act as VPN tunnel endpoints once the hosts underthe sites start communicating. These communications are governed by aset of rules 238 configured for each VPN cloud. The rules 238 maygovern, among other things, VPN access permissions and security featuressuch as the level of encryption and authentication used for theconnectivity at the network layer.

The object oriented structure of FIG. 2 thus allows the networkadministrators to define policies in an intuitive and extensiblefashion. Such policies may be defined by simply associating resources tothe policies. This allows for a policy-centric management model wherethe administrator is given the impression that a single logical serverprovides the firewall, bandwidth management, and VPN services across theenterprise. The fact that the policy is enforced on individual policyenforcers in different locations is transparent to the administrator.

III. Policy-Based Network Architecture

FIG. 3 is a more detailed schematic block diagram of the policy server122 according to one embodiment of the invention. The policy server 122preferably includes a management module 302 that allows centralizedcontrol over the policy enforcers 124, 126 from a single console. Thepolicy server 122 further includes a log collecting and archiving module304 and a policy server reports module 316. The log collecting andarchiving module 304 collects information about the status and usage ofresources from the policy enforcers 124, 126 as well as from themanagement module 302, and stores them in an archive database 318. Thepolicy server reports module 316 uses the collected logs and archives togenerate reports in an organized report format.

Referring again to the management module 302, the management module 302preferably includes four sub-modules aiding in the centralized control,namely, a centralized management sub-module 306, policy managementsub-module 308, secure role-based management sub-module 310, andmultiple site connectivity management sub-module 312.

The centralized management sub-module 306 enables a networkadministrator to install and manage individual policy enforcers from acentral location. The network administrator preferably uses a web-basedgraphical user interface to define the policy enforcer's networkconfiguration and monitor various aspects of the device, such as devicehealth, device alarms, VPN connection status, and the like.

The policy management sub-module 308 provides the network administratorwith the ability to create policies that span multiple functionalaspects of the policy enforcer (e.g. firewall, bandwidth management, andvirtual private networks), multiple resources (e.g. users, hosts,services and time), and multiple policy enforcers.

The secure role-based management sub-module 310 provides role-basedmanagement to enable administrators to delegate administrativeresponsibilities to other administrators. This sub-module preferablyprovides for maximum security when it comes to accessing the managementfunctions.

The multiple site connectivity management sub-module 312 allows thenetwork administrator to set-up secure communication channels betweentwo or more remote sites. In doing so, this sub-module leverages thecentralized management sub-module 306, policy management sub-module 308,dynamic routing capabilities of the policy enforcers 124, 126, and themanagement infrastructure to provide virtual private networks across theenterprise with fine grained access control.

FIG. 4 is a more detailed schematic diagram of the central policymanagement sub-module 306 according to one embodiment of the invention.The sub-module includes a policy server installation wizard 404providing an interactive user interface to aid the installation of thepolicy server 122. In this regard, the network administrator has accessto a personal computer connected to a LAN port of the policy server 122via a cross over cable, hub, or the like. The network administratorconnects to the policy server 122 by preferably typing-in a URL of thepolicy server 122 into a standard Internet browser such as MicrosoftInternet Explorer. The URL is preferably of the form of“http://<ipaddress>:88/index.html” where <ipaddress> is the IP addressthat is to be assigned to the policy server. The IP address isautomatically assigned to the policy server when the browser attempts tocontact the address. When the administrator's personal computer sends anaddress resolution protocol request for the IP address, the policyserver detects that a packet directed to port 88 is not claimed, andassumes the IP address.

Once connected, the policy server installation wizard 404 invokes theinteractive user interface to assist the administrator in setting up thepolicy server 122. Among other things, the policy server installationwizard 404 prompts the administrator to specify a server name, server IPaddress, and router IP address. Furthermore, the policy serverinstallation wizard 404 prompts the administrator to select one ofvarious default policies for creating default firewall, VPN, bandwidth,and administrator policies. These policies are then replicated on eachnew policy enforcer registering with the policy server 122.

The centralized management sub-module 306 further includes a policyenforcer installation wizard 406 providing an interactive user interfaceto aid the installation of the policy enforcers 124, 126. As with theinstallation of the policy server 122, the access to the wizard 406 ispreferably web-based using the network administrator's personalcomputer.

Once connected, the policy enforcer installation wizard 406 invokes theinteractive user interface to assist the network administrator insetting up a particular policy enforcer 124, 126. Among other things,the policy enforcer installation wizard 464 prompts the administrator tospecify the policy server IP address, policy enforcer IP address, androuter IP address. The policy enforcer then registers with the policyserver 122 by invoking a URL on the policy server with basic bootstrapinformation of its own. The registration of the policy enforcer allowsthe initialization of the policy enforcer's database 132, 134 with theconfiguration information, as well as the monitoring of the policyenforcer's status and health by the policy server 122.

Prior to registering the policy enforcer with the policy server 122, thenetwork administrator preferably pre-registers the policy enforcer onthe policy server. Such pre-registering allows the creation of aplaceholder node on the policy server for the policy enforcer data forwhen the policy enforcer does in fact register. In this regard, thecentralized management sub-module 306 includes a configuration interface410 allowing the pre-registration of a new policy enforcer.

FIG. 5 is an exemplary flow diagram of a policy enforcerpre-registration and registration process according to one embodiment ofthe invention. In step 401, the policy enforcer is connected to thenetwork and installed at its actual physical location using theabove-described policy enforcer installation wizard 406. The networkadministrator, possessing the new device's serial number, pre-registersthe policy enforcer by adding the new policy enforcer to a device groupin step 403. In this regard, the configuration interface 410 invokes aninteractive graphical interface, such as the one illustrated in FIG. 6,allowing the network administrator to enter a device name 415, serialnumber 417, and location information 419, and further allowing theadministrator to select a device group 421 to which the new policyenforcer is to belong. Actuation of an apply button 423 causes the newpolicy enforcer, in step 405, to contact the policy server 122 bypreferably invoking a URL on the policy server. Once the policy serverhas been contacted, the new policy enforcer transmits its registrationpacket to the policy server. The registration packet includes at least aserial number of the new policy enforcer, as well as the IP addresses ofthe LAN, WAN, and DMS on the policy enforcer. In step 407, thecentralized management sub-module 306 compares the serial number of thenew policy enforcer with the list of policy enforcers pre-registeredwith the policy server 122. If a match is found, the policy server 122proceeds with the registration process by packaging, in step 409, thesettings selected for the policy enforcer during its installationprocess, preferably into an LDAP Data Interchange Format (ldif) file. Instep 411, the file is transmitted to the policy enforcer, preferablyover an HTTPS channel, by invoking a common gateway interface (CGI) onthe policy enforcer. The policy enforcer then uses the file toinitialize its configuration database, such as database 132, 134, instep 413.

Referring again to FIG. 4, the centralized management sub-module 306also includes a global monitor user interface 402 and a data collectorprogram 412, respectively displaying and collecting the health andstatus of all the policy enforcers managed by the policy server 122. Thedata collector program 412 receives health and status information fromeach of the up-and-running policy enforcers it manages, and passes therelevant information to the global monitor user interface. A healthagent running as a daemon in each of the policy enforcers beingmonitored periodically collects data from the device and analyzes itshealth status. The collected data is then transferred to the policyserver 122 when requested by the data collector program 412.

FIG. 7 is a screen illustration of an exemplary global monitor userinterface 402 presenting various types of health and status information.Such information may relate to the health of the device, such as systemload 712 and network usage information 714. The information may alsorelate to current alarms 716 on the device including alarm name, type,description, and the like. The information may further relate to currentVPN connections 718 including connection type, source/destination,duration, and VPN traffic volume.

Referring again to FIG. 3, the policy management sub-module 308 allowsfor policy management of the policy enforcers 124, 126. As discussedabove, all policy management functions are implemented in terms ofresource objects stored in the policy databases 130, 132, 134 includingusers, devices, hosts, services, and time. Preferably, all resources areassociated with default policy settings selected by the administratorduring the installation process. The network administrator views, adds,and modifies the policies centrally via a graphical user interfaceprovided by the policy management sub-module 308. This allows for apolicy-centric management model where the administrator is given theimpression that a single logical server provides the firewall, bandwidthmanagement, and VPN services across the enterprise. The fact that thepolicy is enforced on individual policy enforcers in different locationsis transparent to the administrator.

FIG. 8 is a screen illustration of an exemplary graphical user interfaceprovided by the policy management sub-module 308. The interface includesa resource palette 718 including a list of resource tabs including ausers tab 718 a, devices tab 718 b, hosts tab 718 c, services tab 718 d,and time tab 718 e. The resource palette allows the administrator to addand modify resource definitions from a single console.

Selection of the users tab 718 a causes a display of the user groups 722defined for the system. New users may be added to the group by selectinga particular group and defining various attributes of the user such as alogin name, full name, policy enforcer to which the user belongs,authentication scheme, password, and the like.

Selection of the devices tab 718 b causes a display of various devicemanagement icons for managing the policy server 122 and the policyenforcers 124, 126 as is illustrated in FIG. 9. A policy server systemssettings icon 750 allows the network administrator to view and modifysystem settings like LAN, WAN/DMS IP addresses of the policy server 122.A policy server archive options icon 752 allows specification ofreporting and other database archive options at the policy server 122. Aglobal URL blocking icon 754 allows the administrator to specify a listof unauthorized web sites 116 to be blocked by all the policy enforcers124, 126 of the system. Similarly, a global spam list icon 756 allowsthe administrator to specify a list of email addresses of spammers 118to be blocked by all the policy enforcers.

The administrator may view information on all the policy enforcers 124,126 by selecting icon 758. Information on a specific policy enforcer maybe viewed by selecting a specific policy enforcer 760 under a particulardevice group 761. Such information includes system settings information762, URL blocking information 764, spam list information 766, and thelike, that is specific to the selected policy enforcer. For instance,selection of the policy enforcer's URL blocking information 764 iconcauses a display of various categories 768 of URLs that the networkadministrator may select to block for the selected policy enforcer.

Selection of the hosts tab 718 c causes a display of various hosts(networks) of the system as is illustrated in FIG. 10. A host isorganized based on its physical location and is further associated witha particular policy enforcer 124, 126. Hosts are associated with variousattributes including a unique name 770, an IP address of the network772, and a subnet mask 774. In addition, the administrator may specifywhether the host is an external host 776 belonging to a network that isnot administered by the policy server 122. If the host is an externalhost, the administrator specifies an IP address 778 of the externaldevice to which the host belongs. A device field 780 allows theadministrator to enter the policy enforcer's name to which the hostbelongs. Each host is further associated with a particular group 782assigned by the administrator.

Selection of the services tab 718 d causes a display of various servicegroups supported by the policy server 122 as is illustrated in FIG. 11.Such service groups include, for example, multimediastreaming/conferencing, information retrieval, security andauthentication, mail applications, routing applications, databaseapplications, standard communication protocols and the like. Users mayalso add new service groups as desired.

Each service is associated with a name 784, description 786, and servicetype 788 (e.g. HTTP, HTTPS, FTP, TELNET, SMTP, Real Networks, and thelike) Furthermore, each service is associated with a service group 790.Based on the type of service, additional information may also bespecified for the service. For instance, for an HTTP service, theadministrator may specify whether URL blocking 792 is to be enabled.

Selection of the time tab 718 e causes a display of various time groupicons 794 covering a range of times to be used in the firewall policiesas is illustrated in FIG. 12. For instance, selection of a work timegroup icon allows the network administrator to set the days and timeswhich are to be set as working days and hours.

Referring again to FIG. 8, the interface also includes a policy canvas720 including a list of policies available to the system. A policydefinition is preferably an association of a set of resources that maybe dragged from the resource palette 718 and dropped onto the policycanvas 720.

Selection of a firewall tab 720 a causes a display of all the firewallpolicies defined for a particular policy domain including one or morepolicy enforcers. The network administrator decides the domain to whicha policy enforcer is to belong during pre-registration of the policyenforcer. The interface allows the network administrator to view, add,and modify the various policies from the policy server 122 andeffectuate the changes on the policy enforcers 124, 126 without the needto make such changes individually in each policy enforcer.

According to one embodiment of the invention, each firewall policyincludes a policy identifier (ID) attribute 724 for identifying aparticular policy rule in the list of policies. An order numberattribute 726 for the policy rule indicates the sequence in which thepolicy is to be applied. In this regard, the policy enforcer 124, 126for the local network takes one rule at a time, in sequence, compares itagainst the network traffic, and preferably applies the first rule thatmatches the network traffic.

Each firewall policy also includes a description attribute 728 fordescribing the firewall policy to be applied. For instance, thedescription may indicate that the policy allows spam blocking, URLblocking, VPN key management, and the like. An action flag attribute 730indicates whether traffic is to be allowed or denied for the indicatedpolicy. An active flag attribute 732 indicates whether the policy hasbeen activated or de-activated. Thus, the network administrator maycreate a policy and activate it at a later time. A policy that has beende-activated preferably has no effect on the network traffic.

Each firewall policy further includes a user attribute 734, sourceattribute 736, service attribute 738, destination attribute (not shown),and time attribute (not shown). Each of these attributes is preferablyrepresented by a group name or a resource name. The name acts as apointer to an entry in the group root object 202 or resource root objectof the LDAP database 130, 132, or 134.

Preferably, the user attribute 734 indicates the user groups and usersthat are eligible for the policy. The source attribute 736 indicates apoint of origination of the network traffic associated with the user.The services attribute 738 indicates the services to the allowed ordenied by the policy. The destination attribute indicates a specificLAN, WAN, DMS segment or specific hosts where the specified services areto be allowed or denied. For example, to configure SMTP pop services ona mail server, the host may be the IP address where the mail server isrunning, and the services specified is SMTP. The time attributeindicates a time slot in which the policy is to be effective, Inaddition to the above, each firewall policy also includes anauthentication attribute (not shown) indicating an authentication schemefor the policy (e.g. none, LDAP, SecurID, RADIUS, WinNT, or all).

FIG. 14 is a screen illustration of an exemplary graphical userinterface for adding a new firewall policy to the policy domain uponactuation of an add button 725. Existing firewall policies may also bemodified or deleted by actuation of a modify button 727 and a deletebutton 729, respectively.

As illustrated in FIG. 14, a new firewall policy may be defined bysimply adding a description of the policy in a description area 728 a,selecting an action to be applied to the matching network traffic in anaction box 730 a, and indicating in an active area 732 a whether thepolicy is to be active or inactive. Furthermore, the networkadministrator specifies the user, source, services, destination, andtime resources in a user area 734 a, source area 736 a, services area738 a, destination area 739 a, and time area 741, respectively. Thenetwork administrator further selects an authentication scheme for thepolicy in an authentication area 743. Upon actuation of an OK button745, appropriate entries of the policy server database's LDAP tree aresuitably changed to reflect the addition of the new policy. The changeis also transmitted to the respective policy enforcers as is describedin further detail below.

Referring again to FIG. 8, selection of the bandwidth tab 720 c allowsthe display, addition, and modification of various bandwidth policiesdetermining the kind of bandwidth to be allocated to a traffic flowingthrough a particular policy enforcer. Different bandwidths may bespecified for different users, hosts, and services.

Selection of the administration tab 720 d allows the display, addition,and modification of various administrative policies allowing a headnetwork administrator to delegate administrative responsibilities toother administrators. In this regard, the head network administratorspecifies administration policies that determine which users have accessto what functions, and for what devices. Preferably the administrationpolicies include similar attributes as the firewall rules except for thespecification of a role attribute. Extra administrative privileges maybe afforded to certain users depending on their role.

IV. Virtual Private Network Having Automatic Reachability Updating

Referring again to FIG. 3, the multi-site connectivity management module312 allows the creation of dynamically routed VPNs where VPN membershiplists are automatically created without statically configuring themembership information by the network administrator. Thus, once theadministrator configures a VPN from one policy enforcer's LAN toanother, routing protocols such as RIPv1 or RIPv2 running on the LANinterfaces learn about the networks reachable through their respectiveinterfaces. These networks then become the VPN's members, and the policyenforcers 124, 126 on either side of the VPN create membership tablesusing the learned routes. The membership information is preferablyexchanged between the policy enforcers 124, 126 through the LDAPdatabases 132, 134. Thus, the combined use of routing protocols and LDAPallows the creation of VPNs whose member lists are dynamically compiled.

Referring again to FIG. 8, the network administrator configures VPNpolicies for multiple site connectivity using the resource palette 718and policy canvas 720. Selection of the VPN tab 720 b in the policycanvas 720 causes the display of a collection of VPN clouds 270 alreadyconfigured for the system as is illustrated in FIG. 13. As describedabove, a VPN cloud is an individual VPN or a group of VPNs for which asecurity policy may be defined. Each VPN cloud includes a list of sitesunder a sites node 234 and users under a users node 236, who cancommunicate with each other. A site is a set of hosts that arephysically behind one of the policy enforcers 124, 126. The policyenforcers for the sites preferably act as VPN tunnel endpoints once thehosts under the sites start communicating.

The users in the VPN cloud are the users who may access the hostsassociated with the sites 234. The users access the hosts as VPN clientsusing VPN client software installed in each user's personal computer asis described in further detail below.

Each VPN cloud 270 further includes a firewall rules node 276 includingfirewall rules to be applied all the connections in the cloud. The rulesmay govern, among other things, VPN access permissions, securityfeatures such as the level of encryption and authentication used for theconnectivity at the network layer.

The hierarchical organization provided by the VPN clouds thus allows thenetwork administrator to create fully meshed VPNs where every sitewithin a VPN cloud has full connectivity with every other site. Thenetwork administrator need no longer manually configure each possibleconnection in the VPN, but only need to create a VPN cloud and specifythe sites, users, and rules to be associated with the VPN. Eachconnection is then configured based on the configuration specified forthe VPN cloud. The hierarchical organization thus facilitates the setupof a VPN with a large number of sites.

The network administrator preferably adds a new VPN cloud by actuatingan add button 280. In response, the policy server 122 automaticallycreates the sites node 272, users node 274, and rules node 276 under theVPN cloud. The administrator then specifies the sites and users in theVPN.

According to one embodiment of the invention, the rules node 276initially includes a default VPN rule 278 corresponding to the policysettings selected by the network administrator during setup of thepolicy server 122. The default VPN rule 278 allows unrestricted accessbetween the hosts in the VPN.

The administrator may implement the access control within the VPN cloudby deleting the default rule 278 and adding specific firewall rules tothe VPN. Such firewall rules allow the administrator to have finegrained access control over the traffic that flows through the VPN, allwithin the realm of the encrypted access provided by such VPN. Thefirewall rules are applied to the cleartext packet after it is decryptedor before it is encrypted.

According to one embodiment of the invention, the administrator selectsthe default rule 278 to effectuate such changes to the default rule.Selection of the default rule invokes a graphical user interface similarto the one illustrated in FIG. 8. The network administrator then finetunes the access to the VPN by defining the firewall rules applicable tothe VPN. The parameters in these firewall rules are preferably identicalto the general firewall rules illustrated in FIG. 8.

Once a VPN cloud is configured, VPN membership information isdynamically created by the policy enforcers 124, 126 in the VPN. In thisregard, each VPN site includes a tag identifying the hosts included inthe site. At runtime, the policy enforcers 124, 126 for the respectivesites associate IP addresses to the tag identifying the hosts in eachsite. This allows the IP addresses to be dynamically discovered withoutrequiring static configuration of the IP addresses.

After the creation of the membership tables, any changes in the routinginformation is detected and notified to the member policy enforcersusing a publish/subscribe process. The actual changes are retrieved by apolicy enforcer by querying the LDAP database on the particular networkthat corresponds to the changed routing information.

FIG. 15 is a schematic functional block diagram of policy enforcers 124,126 at opposite ends of a VPN tunnel updating their respective routinginformation. As illustrated in FIG. 15, each policy enforcer 124, 126includes a gated module 252, 261 configured as a daemon to run one ormore routing protocols for exchanging routes on the network. Suchrouting protocols may include RIPv1, RIPv2, OSPF, and the like.

When a network administrator wishes to add a new route to the privatelocal network 102 connected to policy enforcer 124, the administratorsubmits, in step 241, the new route to a gated module 252 in the policyenforcer 124. This is typically done by configuring a downstream of thepolicy enforcer to have an additional network. This information is thenpropagated by standard routing protocols to the gated module 252 of thepolicy enforcer 124. For example, the policy server 122 may publish thenew route to the policy enforcer 124 with which the new route is to beassociated. The route may be specified, for example, by an LDAPstatement such as “LAN_Group@PR1,” which specifies a new route from apolicy enforcer PR1 to a LAN named LAN_Group. The gated module 252, instep 242, writes the new route to a kernel 253 of the policy enforcerincluding a VPN driver 254 so that the policy enforcer 124 can properlydirect appropriate messages along the new route. Furthermore, the gatedmodule 252, in step 243, writes the new route to its LDAP database 132.

The gated module 252 also provides, in step 244, the name of the newroute to a distinguished name monitor (DNMonitor) daemon 255 configuredto listen for updates in the LDAP database 132. The DNMonitor in turnnotifies, in steps 245 a, 245 b, a VPN daemon 256 and a policydeployment point (PDP) engine 257 of the change in the LDAP database132. The PDP engine then updates the modules that enforce the policies,with the change.

The VPN daemon 256, in step 246, uses the route name to access the LDAPdatabase 132 to get the complete route information, a list of all VPNsto which the new route belongs, and a list of all other policy routersconnected to those VPNs. In step 247, the VPN daemon 256 proceeds tosend the new route name to each of the other policy routers.

When policy router 126 receives a new route name from policy router 124,its network daemon 258, in step 248, accesses the LDAP database 132 inthe sending policy router 124 to obtain the complete new routeinformation. If the new route belongs to more than one VPN and hasdifferent parameters for the different VPNs, routers on the differentVPNs retrieve different information corresponding to the individualVPNs.

In step 249, the network daemon 258 writes the new route informationobtained in its own LDAP database 134 and provides it to its ownDNMonitor module. As in the sending policy router 124, the DNMonitormodule 259 in the receiving policy router 126 provides the new routeinformation to its PDP engine 260 for updating its kernel 265 with thelatest changes.

Although FIG. 15 has been described in connection with addition of aroute to a policy enforcer and its associated VPNs, it should be readilyapparent to those skilled in the art that essentially the sametechniques may be applied to deletion of a route (for example, if anetwork component becomes inoperative or incommunicative), or change ofa route (the policy router may recognize that a route already exists ina different form and simply overwrite it). In this way, the VPN systemor systems can dynamically maintain routing information between itspolicy enforcers with minimal intervention by the system administrator.

V. Virtual Private Network Having Automatic Updating of ClientReachability Information

Remote users communicate over the public Internet 108 with the othermembers of the VPN behind policy enforcers 124, 126, upon presentingappropriate credentials. These remote users access the private networksas VPN clients 140 using a VPN client software. According to oneembodiment of the invention, the system allows the remote user todownload a self-extracting executable which, upon execution, installsboth the VPN client software and VPN reachability information unique tothe remote user in the user's remote terminal.

Each policy enforcer 124, 126 preferably maintains a copy of theself-extracting executable of the VPN client software including a setupprogram and VPN reachability configuration template. The setup programallows the VPN client software to be installed on the VPN client 140.When downloading the self-extracting executable, the configurationtemplate is replaced with the VPN reachability information that isspecific to the downloading user.

According to another embodiment of the invention, the system allows theVPN client 140 to download a self-extracting executable which, uponexecution, only installs the VPN reachability information that is uniqueto the user. According to this embodiment, the VPN client software isalready installed on the VPN client 140. In this scenario, the setupprogram allows the installation of the reachability information that isspecific to the downloading user, on the VPN client 140.

According to a third embodiment of the invention, the system allows theVPN client 140 to automatically download the VPN reachabilityinformation each time it connects to the policy enforcer 124, 126. Thus,VPN reachability information is kept up-to-date for each VPN client 140.Once a VPN session is established, the connection between the VPN client140 and the policy enforcer is assumed to already be secure. The VPNclient preferably makes a common gateway interface (CGI) query to a webserver running on the policy enforcer, and downloads the current VPNreachability information from the corresponding LDAP database.

FIG. 16 is a block diagram of components in a self-extracting executable290 according to one embodiment of the invention. The self-extractingexecutable 290 may be created using commercially available tools such asthe INSTALLSHIELD EXEBUILDER of InstallShiled Software Corporation ofSchaumburg, Ill.

The self-extracting executable 290 preferably includes an executablesetup file 292 for installing the VPN client software and/or the VPNconfiguration information. The setup file 292 preferably forms a staticportion 298 of the self-extracting executable since this informationdoes not change based on the downloading VPN client. The self-extractingexecutable 290 further includes VPN configuration file templates for theVPN reachability information 294 and the VPN client's preshared keyinformation 296. The VPN reachability information 294 and the VPNclient's preshared key 296 preferably form a dynamic portion 299 of theself-extracting executable 290 since this information changes based onthe downloading VPN client. The self-extracting executable 290 is thensaved as a template file in the policy enforcers 124, 126 and is readyto the downloaded by the remote users.

FIG. 17 is a functional block diagram for downloading theself-extracting executable 290 of FIG. 16 according to one embodiment ofthe invention. In step 320, a new VPN client 140 first establishes asecure communication session with the policy enforcer 124, 126 todownload the self-extracting executable 290. Preferably, this isaccomplished via an HTTPS protocol session on the VPN client's webbrowser or the like. In steps 322 and 324, the policy enforcer engagesthe VPN client in an authentication procedure where the policy enforcerrequests, and the VPN client provides, his or her user name andpassword. In step 326, the policy enforcer compares the providedinformation with entries in its VPN client database 328. If theinformation is correct, the policy enforcer finds appropriate presharedkeys for the user, and in step 330, also determines the VPN reachabilityinformation of the client from a VPN configuration database 332. The VPNclient database 328 and VPN configuration database 332 may reside aspart of a single LDAP database 312, 314 managed by the policy enforcer124, 126, or may constitute separate LDAP databases.

In step 334, the policy enforcer replaces the dynamic portion 299 of theself-extracting executable 290 with the VPN reachability information andpreshared key that is unique to the VPN client. The newly generatedself-extracting executable is then downloaded to the VPN client 140 instep 336. When the executable is run, it either installs the VPN clientsoftware and/or the VPN reachability information.

Similar techniques may also be used for downloading a new and updatedcopy of the VPN configuration information to the VPN client each timethe client connects to the policy enforcer and negotiates a session key.In addition, the user may obtain the latest configuration of the VPNnetwork by expressly requesting the policy enforcer for suchinformation. Thus, the VPN client need not be reinstalled andreconfigured each time updates are made to the VPN reachabilityinformation.

VI. Integated Policy Enforcer

According to one embodiment of the invention, the functionalities of thepolicy enforcer 124, 126 for policy enforcement are partitioned foreffective hardware implementation. However, it should be apparent to oneskilled in the art that some or all of the functionalities may beimplemented in software, hardware, or various combinations thereof.

FIG. 18 is a schematic block diagram of the policy enforcer 124, 126illustrating the partitioning of the various functionalities accordingto one embodiment of the invention. The policy enforcer includes anInternet protocol security (IPSec) engine 502 for performing securityand authentication functions in implementing, for instance, virtualprivate networks. A stream table 506 assembles the packets passingthrough the policy enforcer into streams. A protocol classificationengine 508 decodes the protocols used in forwarding the packets. Apolicy engine 510 enforces policies for the packets based on the policysettings stored in the policy database 132, 134. A packet forwardingmodule 504 receives packets from the public Internet via the router 110and buffers, forwards, or drops the packets based on the policies beingenforced. A bandwidth management module 514 provides bandwidth shapingservices to the packets being forwarded based on the bandwidth settingsstored in the policy database 132, 134.

In practice, an incoming packet is matched against the stream table 506for determining if a matching entry already exists in the table. If not,a new entry is added. The stream table preferably includes enoughportions of the packet to uniquely identify a stream. For example, inenforcing policies on IP layer three through layer four traffic, thestream table may store a source IP, destination IP, source port,destination port, and protocol number of the incoming packet.

The protocol classification engine 508 takes the new stream and obtainsa detailed protocol decode for the stream. The policy engine 510 is thenqueried for the policy rules to be applied to the stream. Based on thepolicy rules returned by the policy engine 510, the packet forwardingmodule 504, IPSec engine 502, and/or the bandwidth management module 514process the streams accordingly. The processing may be recursive untilthe packets in the stream have had all the actions specified by thepolicy rule set applied to them.

The policy enforcer also includes a statistics module 512 for collectingstatistics on the packets forwarded through the local network as well asother status and resource usage information, and provides the same inlogs and archives for sending to the policy server 122. According to oneembodiment of the invention, the statistics module 512 keeps runningbyte counts of the packets passing through the network 102, 104. Thesebyte counts may be automatically sorted by classes, such as classesbased on certain resources (e.g. users, hosts, services), as well as bybytes that are blocked by policies and exceptions, such as firewallpolicies. In this regard, the statistics module 512 maintains in a cachea state table including a list of resources involved for each connectionallowed through the firewall. For every packet flowing through theconnection, the statistics module increments the packet and byte countfor each of the resources in the list. The statistics module 512 thenforwards the organized information to the policy server 122 which entersthe information directly into tables organized by classes and aged outperiodically.

FIG. 19 is a more detailed schematic block diagram of the policy engine510 according to one embodiment of the invention. The policy engine 510includes a policy request table 602 that acts as a queue for all thepolicy decision requests. In this regard, the portion of the packetmatching the information stored in the stream table 506 is presented tothe policy engine 510 in the form of a policy request. The policyrequest is then queued in the policy request table 602.

A resource engine 604 maintains an up-to-date mapping of resource groupnames to member mappings. A policy rules database buffer 608 stores acurrent policy rule set to be applied by the policy engine 510. Thepolicy rules stored in the buffer 608 are preferably in the originalgroup-based rule specification format. Thus, the buffer 608 stores arule created for a group in its group-based form instead ofinstantiating a rule for each member of the group.

A decision engine 606 includes logic to serve the incoming policydecision requests in the policy request table 602 by matching it againstthe policy rule set in the policy rules database buffer 608 based on theactual membership information obtained from the resource engine 604. Therelevant group-based rule matching the traffic is then identified anddecision bits in the stream table set for enforcing the correspondingactions. The decision bits thus constitute the set of actions to beperformed on the packets of the stream. All packets matching the streamsare then processed based on these decision bits. The decision engine mayalso specify an access control list (ACL) including a set of rules thatallow/deny traffic, a DiffServ standard for providing a quality ofservice level to the traffic, and/or VPN implementation information.

FIG. 20 is a more detailed schematic block diagram of the protocolclassification engine 508 according to one embodiment of the invention.As illustrated in FIG. 20, the protocol classification engine 508includes a stream data assembly 702, a sliding stream data window 704,an ASN.1 block 706, a protocol classification state machine 708, and aprotocol definition signature database 710. The stream data assembly 702extracts and re-assembles the data portion of an input packet stream andstores it in the sliding stream data window 704. Preferably, the slidingstream data window follows first-in-first-out protocols. The ASN.1decoder further decodes the data stream, if needed, per conventionalASN.1 encoding/decoding standards. The protocol classification statemachine 708 then matches the fully re-assembled and decoded data againstthe protocol definition signature database 710. This database 710preferably holds a mapping of protocol names to data patterns to befound in the data stream. The matched protocol is then returned to thestream table 506.

Thus, the protocol classification engine 508 provides extensive layerthree through layer seven protocol decode and packet classification,including complete identification of dynamic streams using a dynamicallyupdated signature database compiled from scripted protocol definitions.As new protocols are defined in the future and/or users create their owncustom applications with custom protocols, a need may arise to addrecognition of these protocols to the protocol classification engine.The described protocol classification engine architecture allows suchadditions by simply adding a new scripted definition of the new protocolto the protocol classification engine without having to change thedesign each time a new protocol is added. This allows for customprotocol support and future protocol extensibility.

FIG. 21 is a more detailed schematic block diagram of the IPSec engine502 according to one embodiment of the invention. As illustrated in FIG.21, the IPSec engine 502 includes a Pseudo-Random Number Generator(PRNG) function 802 for generating random numbers used for cryptographickey generation according to well known methods. A Diffie Hellman 804 andRSA 812 blocks implement the corresponding asymmetric public keyencryption/decryption/signature algorithms which are also well known inthe art. An IKE block 806 communicates with an IPSec SA table 808 forimplementing standard ISAKMP/Oakley (IKE) key exchange protocols. Acryptographic transforms block 814 implements standard symmetricencryption/decryption algorithms. An IPSec Encapsulation/Decapsulationblock 810 performs standard encapsulation/decapsulation functions.Accordingly, the IPSec engine 502 provides mature, standards-basedIKE/IPSec implementation with public key certificate support andnecessary encryption/decryption functionality for packets passingthrough the private local networks 102, 104.

VII. Network Policy Logs and Statistics Aggregation

Referring again to FIG. 3, the log collecting and archiving module 304collects information about the status and usage of resources from thepolicy enforcers 124, 126 as well as from the management module 302, andstores them in the archive database 318. The policy server reportsmodule 316 then uses the collected logs and archives to generate reportsin an organized report format.

According to one embodiment of the invention, each policy enforcer 124,126 maintains a log file with information collected about the flow oftraffic through the policy enforcer as well as the status and usage ofresources associated with the policy enforcer. All the log files followa predefined common log format, preferably designed to create compactlogs.

FIG. 22 is a schematic layout diagram of such a log format according toone embodiment of the invention. Each log entry includes a timestamp 820in the format yyyymmddhhmmss, indicative of the year, month, date,hours, minutes, and seconds in which the log entry was created. Aservice field 822 indicates the type of service rendered by the policyenforcer 124, 126. Such services include VPN, FTP, Telnet, HTTP, packetfilter, bandwidth, and the like. Each log entry further includes asource IP address and port 824 indicating the source from where a packetwas received, as well as a destination IP address and port 826indicating the destination to which the packet was forwarded.

A user ID field 828 identifies the user transmitting the packet. Theuser ID may be mapped to an entry in the LDAP database 130, 132, or 134for obtaining additional details about the user.

A status field 830 indicates the status of an operation and may includea result code, error code, and the like. For example, for a packetfilter service, the status field may include a result code “p” if thepacket was passed or code “b” if the packet was blocked.

An operation field 832 indicates codes for a type of operation conductedby the service. For instance, operations for a VPN service may includesending packets and receiving packets.

Operations for an FTP service may include GET and PUT operations.Operations for an HTTP service may include GET and POST operations.

In addition to the above, each log entry includes an in-bytes field 832indicative of the number of bytes the policy enforcer received as aresult of the activity, and an out-bytes field 834 indicative of thenumber of bytes transferred from the policy enforcer. Furthermore, aduration field 836 indicates the duration (e.g. in seconds) of theactivity.

Certain fields of a particular log entry may be left blank if notapplicable to a particular service. For instance, for an FTP download.Where there is no outgoing traffic, the out-bytes field is left blank.Furthermore, additional fields may be added based on the type of servicebeing logged. For instance, for an HTTP activity, the URL that isaccessed is also logged in the log entry. The additional fields arepreferably appended to the end of the standard log format.

A person skilled in the art should recognize that additions, deletions,and other types of modifications may be made to the log format withoutdeparting from the spirit and the scope of the invention as long as thelog format common to all the policy enforcers and is aimed in creatingcompact logs.

The log files created by the policy enforcers 124, 126 are transferredto the policy server 122 based on archive options set by the policyserver. In this regard, the network administrator specifies a thresholdsize for the logs created by the policy enforcers upon selection of thepolicy server archive option 752 of FIG. 9. When the log file exceedsthe specified size, it is sent to the policy server 122. Preferably, thelogs are transferred to the policy server 122 at least once a day evenif the threshold size has not been exceeded. The logs may also bearchived locally at the policy enforcer if so specified by the networkadministrator.

Once the policy server 122 receives the logs, it is stored in thearchive database 318 preferably taking the form of an SQL database. Thepolicy server reports module 316 queries this database to generatereports for each policy enforcer 124, 126. In addition, the logs may beexported in a format that may be interpreted by commercially availableproducts such as WEBTRENDS, manufactured by WebTrends Corporation ofPortland, Oreg.

The reports created by the reports module 316 include summary usagereports for the various resources including policy enforcers, users,services, hosts, and VPNs. For instance, the reports may include VPNsummary reports, bandwidth summary reports, packet filter reports, andthe like, for each policy enforcer.

The reports preferably show usage of each of the resources over a periodtime. The start and the end date for the report may be specified by theuser. The user may further drill down on the time dimension and on theresource dimension for viewing specific times and specific resources.For instance, in creating the packet filter reports, the user mayindicate a start and end time, source IP address, source port,destination IP address, and destination port. All packets meeting thesecriteria are then fetched from the archive database 318 and shown in apacket report.

VIII. Method for Selective LDAP Database Synchronization

According to one embodiment of the invention, the databases 130, 132,134 in the unified policy management system of FIG. 1 are LDAP databasesstoring policy management information including policies for firewall,VPNs, bandwidth, administration, user records, network records,services, and the like. As described above, the LDAP directory servicemodel is based on entries where each entry is a collection ofattributes. Entries are arranged in a tree structure that follows ageographical and organizational distribution. Entries are namedaccording to their position in the hierarchy by a distinguished name(DN).

The policy server 122 preferably stores the policy managementinformation for all the policy enforcers in the policy server database130. This information is organized in the databases 130 as one or moreDNs with corresponding attributes. Appropriate portions of the policyserver database are then copied to the policy enforcer databases 132,134.

FIG. 23 is a block diagram of an LDAP tree structure including an LDAProot 265 and a plurality of branches 264, 266, 268, 270. According toone example, the policy server 122 maintains in the policy serverdatabase 130 branches 264 and 266 with policy management information forall the policy enforcers 124, 126. Each of the policy enforcers 124, 126also maintain portions of the branches 264 and/or 266 in theirrespective policy enforcer databases 132, 134 as sub-trees of the policyserver database 130. The portions of the branches maintained by eachpolicy enforcer 124, 126 preferably relates to the configurationinformation for that policy enforcer as well as some additionalinformation about the other policy enforcers. This additionalinformation is used to communicate with the other policy enforcers.

The policy server 122 may further maintain branch 268 storinginformation used only by the applications running on the server and notshared with any of the policy enforcers 124, 126. Likewise, policyenforcers 124, 126 may maintain a portion of branch 268 containinginformation used only by the applications on each of the policyenforcers and not shared elsewhere. Typically, the data stored in branch268 is dynamically generated and used by the applications running on thecorresponding server or agent.

Branch 270 is preferably only included in the LDAP tree for the policyserver database 130 and stores logged policy management changes that maybe propagated to the policy enforcers 124, 126. Such changes mayinclude, for example, addition, deletion, or modifications of a user ona device, VPN cloud, bandwidth policy, or firewall policy made by thenetwork administrator via the various graphical user interfacesdescribed above. Such changes result in the updating of the policydatabase 130 where the corresponding DN of the LDAP tree is added,deleted, or modified. The policy server 122 further creates a log of thechanges and stores them in branch 270 for later distribution to thepolicy enforcers 124, 126.

FIG. 24 is a more detailed block diagram of branch 270 of the LDAP treeof FIG. 23. The LDAP root 265 includes an ApplyLog 270 a entry which inturn includes a user log entry 270 b and a device log entry 270 c. Theuser log entries include specific administrator log entries identifiedby specific DNs 270 d for reflecting the changes made by the particularadministrators. The device log entry 270 c includes specific device logentries identified by specific DNs 270 e reflecting the changes that areto be distributed to the particular policy enforces 124, 126.Preferably, the changes made by the administrators are propagated to thepolicy enforcers 124, 126 upon actuation of an apply button such as theapply button 417 illustrated in FIG. 6.

FIG. 25 is a flow diagram for logging and propagating LDAP changes tothe policy enforcers according to one embodiment of the invention. Instep 420, a particular network administrator makes a policy settingchange. According to one example, the administrator is administrator“adm” working in the domain “domain1,” and the change is the addition ofa new user on a device.

In step 422, the change made the administrator is reflected in thepolicy server database 130. In this regard, branches 264 and 266 of theLDAP tree are modified accordingly to reflect the change in the policysetting. Additionally, in step 424, the policy server 122 creates a logof the changes for the administrator for later processing and sending tothe appropriate policy agent. In step 426, the policy server 122 updatesthe administrator's log DN 270 d to reflect the change. In the aboveexample and as illustrated in FIG. 24, if the log created is named“A_L1,” the policy server 122 updates the DN 270 d for “adm” at“domain1” to create an attribute “apply” 270 f that has the value “A_L1”270 g. Other changes made by the administrator are reflected in separatelogs (e.g. “A_L2,” “A_L3”) and appended to the existing value of theapply attribute in the administrator's log DN 270 d.

In step 428, the policy server 122 checks whether the changes made bythe administrator are to be propagated to the appropriate policyenforcers 124, 126. As discussed above, the changes are preferablypropagated upon actuation of an apply button from the administrator'sgraphical user interface.

If the apply button has been actuated, the policy server creates, instep 430, a log for each policy enforcer to whom the change is to betransmitted. In this regard, the policy server 122 collects all thechanges made by the administrator as reflected in the values 270 g, 270h of the apply attribute 270 f of the administrator's log DN 270 d.These changes are processed for each policy enforcer belonging to theadministrator's domain. Such processing preferably involves picking therelevant changes and suitably modifying the DNs for the policyenforcer's LDAP. Such suitable modifications may be necessary, forinstance, due to the differences in the tree structures in the policyserver database 130 and the policy enforcer databases 132, 134. Forinstance, a change in the administrator's log may contain a DN thatspecifies the domain name of the policy enforcer. In applying thischange to the policy enforcer, the domain name would not be specified inthe DN since the policy enforcer's tree structure does not include adomain name.

The changes suitably modified for each policy enforcer's LDAP are thenstored in a device log. Each policy enforcer's log DN 270 e is thenmodified to reflect the change to the transmitted to the particularpolicy enforcer. In the above example and as illustrated in FIG. 24, ifthe device log created is named “PE_L1,” the policy server 122 updatesthe DN 270 e for the particular policy enforcer “PE1” at “domain1” tocreate an attribute “apply” 270 i that has the value “PE_L1” 270 j.

In step 432, the apply attribute 270 f for the administrator's log DN270 d is then deleted from the LDAP tree. In step 434, the changescollected for each policy enforcer, as reflected in the values 270 j,270 k of the apply attribute 270 i of the policy enforcer's log DN 270e, are transmitted to the policy enforcer for updating its database 132,134. The changes are sent to the policy enforcers preferably over theHTTPS channel.

In step 436, the policy server 122 checks whether the updates have beensuccessful. In this regard, the policy server 122 waits to receive anacknowledgment from the policy enforcer that the updates have beensuccessfully completed. Upon a positive response from the policyenforcer, the policy server 122 deletes the apply attribute 270 e forthe policy enforcer's log DN 270 e. Otherwise, if the update was notsuccessful (e.g. because the policy enforcer was down), the apply log isre-sent the next time another apply function is invoked. Alternatively,the failed policy enforcer transmits a request to the policy server 122of the log of non-applied changes when it rejoins the network (e.g. byrebooting).

IX. State Transition Protocol for High Availability Units

According to one embodiment of the invention, the policy server 122,policy enforcers 124, 126, as well as other network devices may beconfigured for high availability by maintaining a backup unit inaddition to a primary unit.

FIG. 26 is a schematic block diagram of a high availability systemincluding a primary unit 902 and a backup unit 904. The two units 902,904 communicate with each other by exchanging heartbeats over parallelports 906 a, 906 b and a cable 908. Such parallel ports 906 a, 906 b andcable 908 are conventional components that are commonly available in theart.

The primary unit 902 and the backup unit 904 are each similarlyconnected to other components 910, 912, 914 via ports 920 a, 920 b, 922a, 922 b, 924 a, 924 b, respectively. These components 910, 912, 914 maybe hubs, switches, connectors, or the like. Because the primary unit 902and backup unit 904 provide similar services and functions and may beused interchangeably, each unit is preferably connected to the samecomponents 910, 912, 914.

The parallel port cable 908 is preferably a conventional laplink cabledesigned to connect two parallel ports and allow communications betweenthem. The primary unit 902 and the backup unit 904 preferablycommunicate with each other via TCP packets over the high-availabilityports 906 a, 906 b. A point-to-point connection preferably existsbetween the primary unit 902 and the backup unit 904 over thehigh-availability ports 906 a, 906 b.

The primary unit 902 is preferably responsible for checking the statusof its network ports for problems or failures. For example, if theprimary unit 902 detects that one of its network ports is inoperable,e.g. port 922 a, the primary unit 902 then checks whether thecorresponding port 922 b in the backup unit 904 is operational. Upondetermining that the corresponding port 922 b in the backup unit 904 isoperational, the primary unit 902 sends a request to the backup unit 904to take over the system functions as the active unit. The primary unit902 then relinquishes its role as the active unit and shuts itself down,allowing the backup unit 904 to take on the responsibilities of theprimary unit 902. When the primary unit 902 restarts operation, thebackup unit 904 receives a request from the primary unit 902 torelinquish its role as the active unit.

When the primary unit 902 is active and does not detect any defects inits ports, it continuously listens on the high-availability port 906 ato keep track of the status of the backup unit 904. The primary unit 902continues to listen on the high-availability port 906 a for signalscoming from the backup unit 904. When the backup unit 904 is up andrunning, it connects to the primary unit 902. Once the connection ismade, the backup unit 904 begins sending heartbeats to the primary unit902. The backup unit 904 continuously sends heartbeats to the primaryunit 902 in predetermined intervals. According to one embodiment of theinvention, the backup unit 904 sends a “Keep Alive” packet including aKEEP_ALIVE command to the primary unit 902 every one second.

The primary unit 902 responds to the “Keep Alive” packet by changing thecommand field of the packet to a KEEP_ALIVE_RESP command andre-transmitting the packet to the sender. If the backup unit 904 doesnot receive a response back from the primary unit 902 for apredetermined period of time (e.g. one second) for one “Keep Alive”packet, the backup unit 904 begins preparing to take over the activerole. Preferably, the predetermined period should not be greater lessthan two consecutive “Keep Alive” packets.

Upon taking the role of the active unit, the backup unit 904 attempts toreestablish a connection with the primary unit 902 at regular intervalsto determine whether the problem or failure in the primary unit has beencured. If the problem or failure has been cured, the backup unit 904relinquishes its control to the primary unit 902 after setting the IPaddresses of all the network interface cards to the assigned value.

In situations where the backup unit 904 takes over the active role fromthe primary unit 902, an alert/alarm is sent to the networkadministrator indicating such a change. In addition, if the primary unit902 does not receive heartbeats from the backup unit 904, an alert/alarmis sent to the administrator indicating that the backup unit has failed.

A situation may arise when both the primary unit 902 and the backup unit904 are fully functional, and the backup unit 904 desires to take overthe active role. In this case, the backup unit 904 transmits a shut-downcommand to the primary unit 902 which then relinquishes control. Thebackup unit 904 continues its role as the active unit until the primaryunit 902 transmits a request to the backup unit 904 to relinquish itsactive role.

According to one embodiment of the invention, the initial statusdetermination protocol of each high availability unit as a primary,backup, or stand-alone unit relies on a self-discovery process. FIG. 27is a flow diagram of an exemplary status discovery process according toone embodiment of the invention. In step 930, a first high availabilityunit (unit X) that has not yet definitively discovered its status as aprimary or a backup unit boots up, and in step 932 assumes the role of abackup unit. In step 934, unit X searches the network for a primary unitand inquires, in step 936, whether a primary unit has been detected. Ifthe answer is YES, unit X tries to connect to the primary unit. If it issuccessful, unit X initializes as the backup unit in step 938. If, onthe other hand, unit X does not detect the primary unit, unit X assumesthe role of the primary unit in step 940.

In step 942, unit X searches the network for a backup unit. If thebackup unit is detected, as inquired in step 944, unit X connects to thebackup unit and initializes as the primary unit in step 946. If, on theother hand, unit X does not detect any other units in the network withina predetermined time, unit X initializes as a stand-alone unit in step948.

Once the primary and secondary units have been initialized,configuration changes of the primary unit are also transferred to thebackup unit in order to keep the two units synchronized. Theconfiguration information is preferably stored in an LDAP database suchas the central policy server database 130 or policy agent databases 124,126.

FIG. 28 is a flow diagram of a process for maintaining configurationinformation synchronized in the primary and backup units. In step 950,the primary unit boots up and in step 952, detects the backup unit. Instep 954, the backup unit receives configuration change information fromthe primary unit if it is functional. Otherwise, the configurationchanges are entered directly into the backup unit by the networkadministrator. If the configuration change is to be received from theprimary unit, the primary unit notifies the backup unit whenconfiguration changes occur in the primary unit. The changes are thentransferred and applied to the backup unit. The backup unit in turntransmits the status of the transfer and the apply back to the primaryunit.

In step 956, the primary unit is checked to determine whether it isfunctional. If it is, the primary unit is likewise updated with theconfiguration change. Otherwise, if the primary unit is not functional,the backup unit takes on the active role and becomes the active unit instep 958. The primary unit may become non-functional and thus, inactive,due failures in the CPU board, the network interface card, or powersupply.

In step 960, the backup unit tags the changes to transfer them to theprimary once the primary becomes functional. Once the primary unitbecomes functional, the primary unit is updated with the tagged changesmaintained by the backup unit as is reflected in step 962.

According to one embodiment of the invention, software updates on theprimary and backup units are also synchronized so as to update theprimary and backup units serially in a single cycle without the need formultiple update cycles. Thus, the network administrator need notduplicate the efforts of updating the backup unit with the sameinformation as the primary unit.

FIG. 29 is an exemplary flow diagram of updating the primary and backupunits when they are both functional. In step 970, an update, such as asoftware update not stored in the LDAP databases, is sent/transmitted tothe primary unit from a management station accessible by the networkadministrator. The primary unit then updates itself in step 972. In step974, the primary unit automatically sends/transmits the updateinformation to the backup unit. In step 976, the backup unit updatesitself with the update information received from the primary unit.

FIG. 30 is an exemplary flow diagram of updating the primary and backupunits when the primary unit is not functional. In step 978, the primaryunit becomes nonfunctional, and in step 980, the network administratorsends/transmits an upgrade directly to the backup unit instead of theprimary unit. In step 982, the backup unit updates itself with theinformation received from the management station and waits for theprimary unit to become functional. Once the primary unit becomesfunctional, the update is automatically sent/transmitted to the primaryunit for upgrading in step 986. The primary unit then updates itself instep 988.

Although the present invention has been described in detail withreference to the preferred embodiments thereof, those skilled in the artwill appreciate that various substitutions and modifications can be madeto the examples described herein while remaining within the spirit andscope of the invention as defined in the appended claims.

For example, the unified policy management system of FIG. 1 should beviewed as illustrative rather than limiting. It should be apparent tothose skilled in the art who are enlightened by the present inventionthat many alternative configurations are possible. For example, theremay be additional networks with policy enforcers or no additionalnetworks at all. Likewise, policy enforcers may not necessarily accessthe policy server through the Internet, but may be connected via othermeans such as a WAN, MAN, etc. In short, the number and type of usersand resources within and without the organization can vary greatly whilestaying within the scope of the invention.

1. A computer network comprising: a first edge device coupled to a firstprivate network, the first edge device configured to create a firsttable with information of member networks reachable through the firstedge device, the first table being stored in a first database; a secondedge device coupled to a second private network, the second edge deviceconfigured to create a second table with information of member networksreachable through the second edge device, the second table being storedin a second database; wherein, the first and second edge devices enablesecure communication between the first and second private networks, andthe first edge device shares the first table with the second edge deviceand the second edge device shares the second table with the first edgedevice.
 2. The computer network of claim 1, wherein the first edgedevice includes logic for: receiving a new route information; storingthe new route information in the first database; and transmitting aportion of the new route information to the second edge device.
 3. Thecomputer network of claim 2, wherein the portion of the new routeinformation is a route name.
 4. The computer network of claim 2, whereinthe second edge device includes logic for: receiving the portion of thenew route information; accessing the first database based on the portionof the new route information; retrieving the new route information fromthe first database; and storing the retrieved route information in thesecond database.
 5. The computer network of claim 1, whereincommunication between the first and second networks is managed accordingto a security policy associated with the networks.
 6. The computernetwork of claim 5, wherein the security policy is defined for asecurity group providing a hierarchical organization of the group, thegroup including member networks, users allowed to access the membernetworks, and a rule controlling access to the member networks.
 7. Thecomputer network of claim 6, wherein each member network has fullconnectivity with all other member networks and the security policydefined for the security policy group is automatically configured foreach connection.
 8. The computer network of claim 6, wherein thesecurity policy provides encryption of traffic among the member networksand the rule is a firewall rule providing access control of theencrypted traffic among the member networks.
 9. In a computer networkincluding a first edge device coupled to a first private network and asecond edge device coupled to a second private network, the first andsecond edge devices enabling secure communication between the first andsecond private networks, a method for gathering membership informationcomprising: creating a first table with information of member networksreachable through the first edge device, storing the first table in afirst database; creating a second table with information of membernetworks reachable through the second edge device; storing the secondtable in a second database; sharing the first table with the second edgedevice; and sharing the second table with the first edge device.
 10. Themethod of claim 9 further comprising: receiving a new route information;storing the new route information in the first database; andtransmitting a portion of the new route information to the second edgedevice.
 11. The method of claim 10, wherein the portion of the new routeinformation is a route name.
 12. The method of claim 10 furthercomprising: receiving the portion of the new route information;accessing the first database based on the portion of the new routeinformation; retrieving the new route information from the firstdatabase; and storing the retrieved route information in the seconddatabase.
 13. The method of claim 9, wherein communication between thefirst and second networks is managed according to a security policyassociated with the networks.
 14. The method of claim 13 furthercomprising defining the security policy for a security policy group, thegroup providing a hierarchical organization of the group includingmember networks, users allowed to access the member networks, and a rulecontrolling access to the member networks.
 15. The method of claim 14,wherein each member network has full connectivity with all other membernetworks and the security policy defined for the security policy groupis automatically configured for each connection.
 16. The method of claim14, wherein the security policy provides encryption of traffic among themember networks and the rule is a firewall rule providing access controlof the encrypted traffic among the member networks.